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Zusammenfassung 

Ziel unserer Arbeit ist es, algorithmische Musik interaktiv und mit mehreren Teilneh- 
mern zu komponieren. Dazu entwickeln wir einen Interpreter fur eine Teilsprache der nicht - 
striktcn funktionalen Programmiersprache Haskell 98, der es erlaubt, das Programm noch 
wahrend seiner Ausfiihrung zu andern. Unser System eignet sich sowohl fur den Live-Einsatz 
zur Musikprogrammierung als auch als Demonstrations- und Lernumgebung fiir funktionale 
Programmierung. 



1 Einfuhrung 

Unser Ziel ist es, Musik durch Algorithmen zu beschreiben. Wir wollen Musik nicht wie auf dem 
Notenblatt als mehr oder weniger zusammenhanglose Folge von Noten darstellen, sondern wir wol- 
len Strukturen ausdruckcn. Bcispiclsweise wollen wir nicht die einzelnen Noten einer Begleitung 
aufschrciben, sondern die Begleitung durch ein allgemeincs Muster und die Folge von Harmonien 
ausdriicken. Als weiteres Beispiel mag ein Komponist dienen, der eine Folge von zufalligen Noten 
verwenden mochte. Er mSchte die Noten aber nicht einzeln aufschreiben, sondern die Idee aus- 
driicken, dass es eine zufallige Folge von Noten ist. Dem Interpreten ware es damit freigestellt, 
eine andere aber ebenso zufallige Folge von Noten zu spielen. 

Der Programmierer soli den Grad der Strukturierung frei wahlen konnen. Beispielsweise soli es 
moglich sein, „von Hand" eine Melodie zu komponieren, diese mit einem Tonmuster zu begleiten, 
fiir das lediglich eine Folge von Harmonien vorgegeben wird, und das ganze mit einem vollstandig 
automatisch berechneten Rhythmus zu unterlegen. 

Mit dem bewussten Abstrahieren von der tatsachlichen Musik wird es aber schwierig, beim 
Programmieren das Ergebnis der Komposition abzuschatzen. Bei Musik, die nicht streng nach 
Takten und Stimmen organisiert ist, fallt es schwerer, einen bestimmten Zeitabschnitt oder eine 
bestimmte Auswahl an Stimmen zur Probe anzuhoren. Auch der klassische Zyklus von „ Programm 
cditieren, Programm priifen und iibersetzen, Programm neu starten" steht dem kreativen Aus- 
probieren entgegen. Selbst wenn Ubersetzung und Neustart sehr schnell abgeschlossen sind, so 
muss doch das Musik erzeugende Programm und damit die Musik abgebrochen und neu begonnen 
werden. Insbesondere beim gemeinsamen Spiel mit anderen Musikern ist das nicht akzeptabel. 

In unserem Ansatz verwenden wir zur Musikprogrammierung eine rein funktionale Program- 
miersprache mit Bedarfsauswertung [5], die nahezu eine Teilsprache von Haskell 98 [5j ist. Unsere 
Bcitragc zur interaktiven Musikprogrammierung sind Konzepte und ein lauffahiges System, wel- 
ches folgendes bieten: 

• Algorithmische Musikkomposition, bei der das Programm verandert werden kann, wahrend 



die Musik lfiuft (Abschnitt 2.1) 
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gleichzeitige Arbeit mehrerer Programmicrer an einem Musikstiick unter Anleitung eines 



„Dirigenten" (Abschnitt 2.2) 



2 Funktionale Live-Programmierung 
2.1 Live-Coding 

Wir wollen Musik ausgeben als eine Liste von MIDI-Ereignissen [7], also Ereignissen der Art 
„Klaviaturtaste gedriickt", „Taste losgelassen" , „Instrument gewechselt", „Klangregler verandert" 
und Warte-Anweisungen. Ein Ton mit Tonhohe C-5, einer Dauer von 100 Millisekunden und einer 
normalen Intensitat soli geschrieben werden als: 

main = 

[ Event (On c5 normalVelocity) 
, Wait 100 

, Event (Off c5 normalVelocity) 

] ; 

c5 = 60 ; 

normalVelocity = 64 ; 

Mit der Listenverkettung „++" lasst sich damit bereits eine einfache Melodie beschreiben. 
main = 

note qn c ++ note qn d ++ note qn e ++ note qn f ++ 
note hn g ++ note hn g ; 

note duration pitch = 

[ Event (On pitch normalVelocity) 
, Wait duration 

, Event (Off pitch normalVelocity) 

] ; 

qn = 200 ; — quarter note - Viertelnote 
hn = 2*qn ; — half note - halbe Note 

c = 60 
d = 62 
e = 64 
f = 65 
g = 67 
normalVelocity = 64 ; 

Diese Melodie lasst sich endlos wicdcrholcn, indem wir am Ende der Melodie wieder mit dem 
Anfang fortsetzen. 

main = 

note qn c ++ note qn d ++ note qn e ++ note qn f ++ 
note hn g ++ note hn g ++ main ; 

Die so definierte Liste main ist unendlich lang, lasst sich aber mit der Bedarfsauswertung schrittwei- 
se berechnen und an einen MIDI-Synthesizer senden. Dank der Bedarfsauswertung kann man die 
Musik als reine Liste von Ereignissen beschreiben. Das Programm muss und kann sclbst kcine Aus- 
gabebefehle ausfiihren. Der Versand der MIDI-Kommandos wird vom Interpreter iibernommen. 



Henning Thielemann 



3 



In einem herkommlichen interaktiven Interpreted wie dem GHCi wiirde man die Musik etwa 
so wiedergeben: 

Prelude> playMidi main 

Will man die Melodie andern, miisste man die Musik beenden und die neue Melodie von vorne 
beginnen. Wir wollen aber die Melodie andern, wahrend die alte Melodie weiterlauft, und dann 
die alte Melodie nahtlos in die neue iibergehen lassen. Mit anderen Worten: Der aktuelle Zustand 
des Interpreters setzt sich zusammen aus dem Programm und dem Zustand der Ausfiihrung. Wir 
wollen das Programm austauschen, aber den Zustand der Ausfiihrung beibehalten. Das bedeutet, 
dass der Zustand in einer Form gespeichert sein muss, der auch nach Austausch des Programms 
einen Sinn ergibt. 

Wir losen dieses Problem wie folgt: Der Interpreter betrachtet das Programm als Menge von 
Tcrmcrsctzungsregeln und die Ausfiihrung des Programms besteht darin, die Ersetzungsregeln 
wiederholt anzuwenden, solange bis der Startterm main so weit reduziert ist, dass die Wurzel 
des Operatorbaums ein Terminalsymbol (hier: ein Datenkonstruktor) ist. Fur die musikalische 
Verarbeitung testet der Interpreter weitcrhin, ob die Wurzel ein Listcnkonstruktor ist und falls 
es eine nichtleere Liste ist, reduziert er das fuhrende Listenelement vollstandig und priift, ob 
es ein MIDI-Ereignis darstellt. Ausfiihrungszustand des Interpreters ist der reduzierte Ausdruck. 
Wahrend der Interpreter die vorletzte Note in der Schleife des obigen Programms wiedergibt, ware 
dies beispielsweise: 

Wait 200 : 

(Event (Off g normalVelocity) : (note 1m g ++ main)) 

Der Ausdruck wird immer so wenig wie moglich reduziert, gerade so weit, dass das nachste 
MIDI-Ereignis bestimmt werden kann. Das erlaubt es zum einen, eine unendliche Liste wie main 
zu verarbeiten und zum anderen fiihrt es dazu, dass in dem aktuellen Term wie oben angegeben, 
noch die Struktur des restlichen Musikstiicks zu erkennen ist. Der abschliefiende Aufruf von main 
ist beispielsweise noch vorhanden. Wenn wir jetzt die Definition von main andern, wird diese 
veranderte Definition verwendet, sobald main reduziert wird. Wir konnen auf diese Weise die 
Melodie innerhalb der Wiederholung andern, beispielsweise so: 

main = 

note qn c ++ note qn d ++ note qn e ++ note qn f ++ 
note qn g ++ note qn e ++ note hn g ++ main ; 

Wir konnen aber auch folgende Anderung vornehmen 
main = 

note qn c ++ note qn d ++ note qn e ++ note qn f ++ 
note hn g ++ note hn g ++ loopA ; 

und damit erreichen, dass nach einer weiteren Wiederholung der Melodie die Musik mit einem 
Abschnitt namens loopA fortgesetzt wird. 

Wir halten an dieser Stelle fest, dass sich die Bedeutung eines Ausdrucks wahrend des Pro- 
grammablaufs andern kann. Damit geben wir eine wichtige Eigenschaft der rein funktionalen 
Programmierung auf. Wenn wir von Live-Anderungen Gebrauch machen, ist unser System also 
nicht mehr referential transparent". Beispielsweise hatten wir die urspriingliche Schleife auch mit 
der Funktion cycle implementieren konnen 

main = 
cycle 

( note qn c ++ note qn d ++ note qn e ++ note qn f ++ 
note hn g ++ note hn g ) ; 



Der Interpreter ware hier im wahrsten Sinne des Wortes der musikalische Interpret 
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und wenn cycle dcfiniert ist als 
cycle xs = xs ++ cycle xs ; 
dann wiirde dies reduziert werden zu 

( note qn c ++ note qn d ++ note qn e ++ note qn f ++ 
note hn g ++ note hn g ) 

++ 

cycle 

( note qn c ++ note qn d ++ note qn e ++ note qn f ++ 
note hn g ++ note hn g ) ; 

Die Schleife konnte dann nur noch verlassen werden, wenn man die Definition von cycle andert. 
Diesc Anderung wiirde aber alle Aufrufe von cycle im aktucllen Term gleichcrmafien bctrcffcn. 
Zudem ware es bei einem strengen Modulsystem ohne Importzyklen unmoglich, im Basis-Modul 
List, in dcm cycle definiert ist, auf Funktionen im Hauptprogramm zuzugreifen. Dies ware aber 
notig, um die cycle-Schleife nicht nur verlassen, sondern auch im Hauptprogramm fortsetzen zu 
konnen. 

Wir erkennen an diesem Beispiel, dass es vorausschauend besser sein kann, mit einer „von 
Hand" programmierten Schleife dcr Form main = ... ++ main eine Sollbruchstelle zu schaffen, 
an der man spater neuen Code einfugen kann. 

Neben der seriellen Verkettung von musikalischen Ereignissen benotigen wir noch die paral- 
lele Komposition, also die simultane Wiedergabe von Melodien, Rhythmen usw. Auf der Ebe- 
ne der MIDFKommandos bedeutet dies, dass die Kommandos zweier Listen geeignet miteinan- 
der verzahnt werden miissen. Wir wollen die Definition der entsprechenden Funktion „=:=" der 
Vollstandigkeit halber hier wiedergeben. 

(Wait a : xs) =:= (Wait b : ys) = 

mergeWait (a<b) (a-b) a xs b ys ; 
(Wait a : xs) =:= (y : ys) = 

y : ((Wait a : xs) =:= ys) ; 
(x : xs) =:= ys = x : (xs =:= ys) ; 
[] =:= ys = ys ; 

mergeWait _eq a xs _b ys = 

Wait a : (xs =:= ys) ; 
mergeWait True d a xs _b ys = 

Wait a : (xs =:= (Wait (negate d) : ys)) ; 
mergeWait False d _a xs b ys = 

Wait b : ((Wait d : xs) =:= ys) ; 

Die grafische Bedienschnittstelle unseres Systems ist in Abbildung[l]zu sehen. Im linken oberen 
Teil kann der Benutzer den Programmtext eingeben. Mit einer bestimmten Tastenkombination 
kann er den Programmtext auf Syntaxfehlcr prlifen und in den Programmspeicher des Interpreters 
ubernehmen. Das vom Interpreter ausgefiihrte Programm ist im rechten oberen Teil zu sehen. In 
diesem Teil hebt der Interpreter aufierdem hervor, welche Teilausdriicke reduziert werden mussten, 
um den vorhergehenden in den aktuellen Ausdruck zu uberfuhren. Auf diese Weise kann man 
den Verlauf der Melodie visuell verfolgen. Der aktuelle Term des Interpreters ist im unteren Teil 
der Bedienoberflache dargestellt. Die in der Abbildung wiedergegebenen Texte entsprechen im 
Wesentlichcn unserem einfuhrcndcn Beispiel, weisen aber unsere Melodie zusatzlich noch einem 
MIDI-Kanal zu und verwenden Dcfinitionen von ++ und map, welche auf f oldr aufbauen. 

Das System verfiigt iiber die Ausfuhrungsmodi „Echtzeit", „Zeitlupe" und „Einzelschritt". 
Der Echtzeit-Modus gibt die Musik wieder, so wie es die Notenlangen erfordern, wahrend die 
anderen beiden Modi die Warte-Ereignisse ignorieren und stattdessen nach jedem Element der 
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RIe Execution Window 



ATPS Bool Controls Function List Midi Prelude Tuple 



module ATPS where 

import Midi 
import List 

main = 

channel ( 

note qn c ++ note qn d ++ note qn e ++ note qn f 

note hn g ++ note hn g ) ++ main j 



qn = 200 ; 
hn = 2+qn ; 

= 60 ; 
= 62 ; 



quarter note 
half note 



Viei telnote 
halbe Note 



import Midi 
import List 

main - 

channel ( 

note qn c ++ note qn d 
note hn g ++ note hn g 



note qn e ++ note qn f 
++ main ; 



200 ; 
2|qn 



quarter note - Viertelnote 
half note - halbe Note 



(Wait 400) 
(folclr cons main 

(map (channelEvent Q) 

(foldr cons (note hn g) (: 



(Event (Off g normalVelocity) ) [])))) 




Abbildung 1: Der Interpreter im Betrieb 



MIDI-Kommandoliste eine Pause machen. Die beiden letzten Modi sind zur Beobachtung der 
Ausffihrung und zur Fehlersuche gedacht. Sie eignen sich auch fur den Einsatz in der Lehre, zur 
Erlauterung, wie ein Interpreter einer funktionalen Sprache mit Bedarfsauswertung im Prinzip 
funktioniert. 

Der Interpreter ist in Haskell mit dem Glasgow Haskell Compiler GHC [10 implementiert und 
verwendet WxWidgets pTJ fur die grafische Bedienoberflache. Die verarbeitete Sprache unterstiitzt 
„Pattern matching", vordcfinicrte Infix-Operatoren, Funktionen hoherer Ordnung, unvollstandige 
Funktionsanwendung. Aus Griinden der einfachen Implementierung gibt es bislang folgende Ein- 
schrankungen: Die interpretierte Sprache ist dynamisch typisiert, und kennt als Objekte ganze 
Zahlen, Texte und Konstruktoren. Sie ist formatfrei, weswegen nach Deklarationen stets Semikola 
gesetzt werden miissen. Viele syntaktische Besonderheiten werden nicht unterstiitzt, beispielsweise 
„List Comprehension", „Operator Section", Do-Notation, Let- und Case-Notation, frei definierbare 
Infix-Operatoren. Ein- und Ausgabeoperationen sind ebenfalls nicht verfiigbar. 

2.2 Verteilte Programmierung 

Unscr System soli es auch erlauben, das Publikum in eine Auffiihrung oder Studcntcn in die Vorle- 
sung durch Programmieren einzubeziehen. Die typische Situation dafiir ist, dass der Vortragcndc 
die Bedienoberflache des Programms an die Wand projiziert, die Zuhorer die crzcugte Musik fiber 
eine Musikanlage horen und dass die Zuhorer fiber ein Funknetz und einen Browser Kontakt mit 
dem Vortragsrechner aufnehmen konnen. 

Die implementierte funktionale Sprache verffigt fiber ein einfaches Modulsystem. Der Vortra- 
gende kann auf diese Weise ein Musikstfick in mehrere Abschnitte oder Tonspuren zerlegen, und 
jeden dieser Teile in einem Modul ablegen. Die Module wiederum kann er Zuhorern zuweisen. Au- 
fierdem kann der Vortragende durch Einffigen eines bestimmtcn Kommentars festlegen, ab welcher 
Zeile der Zuhorer den Modulinhalt verandern darf. In den Zeilen davor stehen fiblicherweise der 
Modulname, die Listc der cxportierten Bezeichner, die Liste der importicrtcn Module und grund- 
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legende Definitioncn. Auf diesc Weise kann dcr Vortragende cine Schnittstellc fiir jedes Modul 
vorgeben. 

Ein Zuhorer kann nun iiber einen WWW-Browser ein Modul abrufen und den veranderbaren 
Teil editieren. (Siehe Abbildung [2| Nach dem Editieren kann er den veranderten Inhalt an den 
Server schicken. Dieser ersetzt im Editor den Modultext unterhalb des Markierungskommentars 
mit dem neuen Inhalt. Dann wird der Text syntaktisch gepriift und im Erfolgsfall an den Interpreter 
weitergeleitet. 1st der Text syntaktisch nicht korrekt, so bleibt er im Editor, damit er notfalls vom 
Vortragenden uberpriift und korrigiert werden kann. 



: Haskell Live Sequencer - Module ATPS - Konqueror 



Dokument Bearbeiten Ansicht Gehezu Lesezeichen Extras Einstellungen Fenster Hilfe 



tun h 



GtQGtO Q Q «j U WW j 9, 



& Adresse: 6 http://localhost:80B0/ATPS 



j -'1, 



ATPS 



• ATPS 

• Bool 

• Controls 

• Function module ATPS where 

• List 

. Midi import Midi 
. Prelude List 

• Tuple 

c = 60 ; d = 62 ; e = 
qn = 200 ; hn = 2*qn 



65 ; g = 67 



main = 

channel C 

note qn c ++ note qn d ++ note qn e 

note hn g ++ note hn g ) ++ main ; 



note qn £ 



[Seite geladen. 



Abbildung 2: Zugriff auf ein Modul iiber das Netz 



Im Allgemeinen wird es nicht gelingen, ohne Vorbereitung auf diese Weise ein vollig ncucs 
Musikstiick zu erschaffen. Der Vortragende kann aber seine Auffuhrung vorbereiten, indem er sich 
eine Aufteilung in Module iiberlegt und diese mit grundlegenden Definitionen fiillt. Dies konnen 
Definitionen von Funktionen sein, die eine Liste von Nullen und Einsen in einen Rhythmus verwan- 
dcln, oder eine Liste von Zahlen in ein Akkordmuster oder eine Bassbegleitung. Der Vortragende 
kann dann durch Vorgabe von Takt und von Harmonien sicher stellen, dass die einzelnen Stiicke 
zusammenpassen. Der Vortragende ubernimmt in diesem Szenario nicht mehr die Rolle des Kom- 
ponisten, sondern eher die Rolle des Dirigcntcn. 



3 Verwandte Arbeiten 



Algorithmische Komposition hat inzwischen eine lange Tradition. Als Beispiele seien hier nur Mo- 
zarts musikalische Wurfclspicle und die Illiac-Suite [3] genannt. Auch gibt es mit Haskore [3] seit 
einiger Zeit die Moglichkeit, Musik in Haskell zu programmieren und damit vcrschicdcne Klanger- 
zeuger iiber MIDI zu steuern oder mit CSound, SuperCollider oder mit in Haskell geschriebenen 
Audiosynthesefunktionen Audiodateien zu erzeugen. Haskore baut ebenfalls auf der Bedarfsaus- 
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wertung auf und crlaubt die elegante Definition von formal grofien oder unendlichen Musikstiicken 
bei geringem tatsachlichem Speicherverbrauch bei der Interpretation. Das kreative Komponieren 
wird allerdings dadurch erschwert, dass man Anderungen erst nach Abbruch und Neustart des 
Programms horen kann. 

Ein sehr popularer Ansatz zur Programmierung von Animationen, Robotersteuerungen, grafi- 
schen Bedienschnittstellen und Audiosignalverarbeitung in Haskell ist die funktionale reaktive Pro- 
grammierung 2 . Wie fur unsere Musikstiicke wird auch hier der zeitliche Verlauf einer Animation, 
einer graphischen Bedienoberflache oder ahnlichem durch eine Art unendliche Liste beschrieben. 
Dariiber hinaus soli ein FRP-Programm auch auf auBere Ereignisse, wie zum Beispiel Bewegungen 
der Computermaus reagieren konnen. Im Gegensatz zu unserer Arbeit ist bisher allerdings nicht 
moglich, ein FRP-Programm wahrend seiner Ausfiihrung zu andern. 

Eine funktionale, aber nicht rein funktionale, Programmiersprache, die Anderungen des Pro- 
grammtextes wahrend der Programmausfuhrung erlaubt, ist Erlang [T]. Erlang folgt der strengen 
Semantik. Man konnte in Erlang eine Folge von MIDFKommandos nicht durch eine (lazy) Lis- 
te von Konstruktoren beschreiben, sondern brauchte Iteratoren oder ahnliches. In ein laufendes 
Erlang-Programm kann neuer Programmcode auf zwei verschiedene Weisen eingebracht werden, 
cntwcdcr in dcm das laufende Programm Funktionen (zum Beispiel Lambda-Ausdriicke) aufruft, 
die ihm als Nachrichten zugesandt werden oder indem ein Erlang-Modul durch ein neues Modul er- 
setzt wird. Wird ein Erlang-Modul nachgeladen, so behalt das Laufzeitsystem die alte Version des 
Moduls im Speicher, um laufende Programmteile ausfiihren zu konnen. Lediglich modul-externe 
Aufrufc springen in das neue Modul, wobei man einen externen Aufruf auch innerhalb desselben 
Moduls starten kann. Auch in Erlang mussen also Sollbruchstellen (externe Aufrufe oder Funkti- 
onsubcrnahme aus Nachrichten) zum spateren Einfugen von neuem Code geschaffen werden. 

Unser Ansatz zur Anderung von Programmtext wahrend der Programmausfuhrung ist damit 
sehr ahnlich zum „Hot Code loading" in Erlang. Die Bedarfsauswertung in unserem Interpreter 
fiihrt jedoch dazu, dass betrachtliche Teile des Programmtextes im aktuellen Term enthalten sind. 
Diese werden von Anderungen an einem Modul nicht unmittclbar betroffcn. Auf dicsc Wcisc ist 
es in unserem Ansatz nicht unbedingt notig, zwei Versionen eines Moduls im Speicher zu haltcn, 
um einen glatten Ubergang von altem zu neuem Programmtext zu erreichen. 

Sogenanntes Musik-Live-Coding, also das Programmieren eines musikerzeugenden Programms, 
wahrend die Musik lauft, war bislang Spezialsprachen wie ChucK [12] und SuperCollider/SCLang 
[B] und ihren Implementierungen vorbehalten. Diese Sprachen sind beim Kontrollfhiss an das impe- 
rative Programmierparadigma angelehnt und beim Typsystem an die objektorientierte Program- 
mierung. Im wesentlichen funktionieren beide wie eine Client-Server-Losung, wobei der Server die 
Klange erzeugt und parallel zu einem Kommandozeileninterpreter lauft, von dem aus man Befehle 
an den Server schicken kann. 

Auch in unserer Architektur lauft die Klangerzeugung parallel zur cigcntlichcn Programmie- 
rung und wird mit (MIDI-)Kommandos gesteuert. Jedoch wird in unserem Ansatz nicht program- 
micrt, wie sich die Klangerzeugung andern soil, sondern das erzeugende Programm wird dirckt 
geandert. 



4 Folgerungen und zukiinftige Arbeiten 

Unsere vorgestellte Technik zeigt einen neuen Weg der Live-Programmierung von Musik auf, 
der sich moglicherweise auch auf die Wartung anderer lange laufender funktionaler Programme 
iibertragen lasst. Dennoch zeigt sich, dass man schon beim Programmieren einer ersten Version 
gewisse Sollbruchstellen vorschen muss, an denen man spater im laufenden Programm Anderungen 
einfugen kann. Auch mit automatischen Optimierungen des Programms mussen wir jetzt vorsich- 
tig sein, denn cine Optimicrung konnte eine solche Sollbruchstcllc cntfernen. Wenn ein Programm 
zur Laufzeit geandert wird, so sind Funktionen eben nicht mehr „referential transparent", womit 
wir eine wichtige Eigenschaft der funktionalen Programmierung aufgeben. 
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Typsystem Um die Gefahr zu verringern, dass ein Musikprogramm nach einer Anderung wegen 
eines Programmfehlers abbricht, ist der nahe liegende nachste Schritt der Einsatz eines statischen 
Typpriifers. Dieser miisste nicht nur testen, ob das vollstandige Programm nach Austausch eines 
Moduls noch typkorrekt ist, sondern er miisste zudem testen, dass der aktuelle Term im Interpreter 
beziiglich des neuen Programms typkorrekt ist. 

Noch wichtiger wird ein Typpriifer im Mehrbenutzerbetrieb. Der Leiter einer Programmier- 
veranstaltung mit mehreren Programmicrcrn konntc jedem Tcilnehmer Typsignaturen im nicht 
cditierbaren Bereich seines Moduls vorgeben, die der Teilnehmer implementieren muss. Der Ty- 
ppriifer wiirde dafur sorgen, dass Tcilnehmer nur Andcrungcn cinschickcn konnen, die zum Rest 
des Musikstiicks passen. 

Auswertungsstrategie Derzeit ist unser Interpreter sehr einfach gehalten. Der aktuelle Term 
ist ein reiner Baum. In dieser Darstellung konnen wir nicht ausdriicken, dass der Wert eines Terms 
mehrmals verwendet wird. (Es gibt also kein „sharing".) Wenn beispielsweise f definiert ist als 
f x = x : x :[], dann wird der Aufruf f (2+3) reduziert zu (2+3) : (2+3) : [] . Wenn weiterhin 
das erste Listenelement zu 5 reduziert wird, wird das zweite Listenelement nicht reduziert. Wir 
erhalten also 5 : (2+3) : [] und nicht 5:5: [] . Da der Term nur ein Baum ist und kein 
Graph, brauchen wir keine eigene Speicherverwaltung, sondern konnen uns auf die automatische 
Speicherverwaltung des GHC-Laufzeitsystems verlassen, in dem der Interpreter lauft. Wenn ein 
Teilterm nicht mehr benotigt wird, so wird er aus dem Operatorbaum entfernt und friiher oder 
spater vom Laufzeitsystem des GHC freigegeben. 

Selbst einfache korekursive Definitionen wie die der Fibonacci-Zahlen durch 

fix (\fibs -> : 1 : zipWith (+) fibs (tail fibs)) 

fiihren bei diesem Auswertungsverfahren zu einem unbegrenzten Anstieg der Tcrmgrofie. In Zu- 
kunft sollen daher weitere Auswertungsstrategien wie zum Beispiel die Graphreduktion mit der 
STG-Maschine jS] hinzukommen, die dieses und weitere Probleme losen. Anstelle eines Opera- 
torbaums wiirde der aktuelle Term dann aus einem Operatorgraph bestehen, die Anwendung 
der Funktionsdefinitionen und damit die Moglichkeit der Live-Anderung einer Definition bliebe 
prinzipiell erhalten. Die Gefahr bei Live-Musikprogrammierung liegt natiirlich darin, dass Pro- 
grammanderungen abhangig von der Auswertungsstrategie verschiedene Auswirkungen auf den 
Programmablauf haben konnen. Das Verwenden des gleichen Objektes im Speicher an verschie- 
denen Stellen im aktuellen Term („sharing") wiirde zwar im obigen Beispiel der Fibonacci-Zahlen 
den Speicherverbrauch begrenzen, k5nnte aber auch verhindern, dass eine geanderte Definition der 
aufgerufenen Funktionen noch beriicksichtigt wird. Der Einzclschrittmodus wiirde es ermoglichen, 
in der Lehre verschiedene Auswertungsverfahren zu demonstrieren und Vor- und Nachteile mit- 
einander zu vergleichen. 

Offen ist, ob und wie wir unser System, das Anderungen des Programms wahrend des Pro- 
grammablaufs zulasst, direkt in eine existierende Sprache wie Haskell einbetten konnen. Dies 
wiirde es uns vereinfachen, die Wechselwirkung zwischen Programmanderungen, Optimierungen 
und Auswertungsstrategien zu untersuchen. 

Hervorhebungen Es gibt noch ein weiteres interessantes offenes Problem: Wie kann man Text- 
stellen im Programm passend zur erzeugten Musik hervorheben? Es liegt nahe, die jeweils gespiel- 
ten Noten hervorzuheben. Dies wird zur Zeit dadurch erreicht, dass in einer Wartephase alle die 
Symbole hervorgehoben werden, welche seit der letzten Wartephase durch den Interpreter reduziert 
wurden. Wenn aber eine langsame Melodie parallel zu einer schnellen Folge von Regleranderungen 
abgespielt wird, so fuhrt das dazu, dass die Noten der Melodie nur kurz hervorgehoben werden, 
namlich immer nur fur die kurze Zeit, in der der Reglerwert konstant bleibt. Wir wurden aber 
erwarten, dass die Hervorhebung eines Musikteils nicht von parallel laufenden Tcilcn becinflusst 
wird. Formal konnten wir es so ausdriicken: Gegeben seien die serielle Komposition ++ und die 
parallele Komposition =:=, die sowohl fur Terme als auch fur Hervorhebungen definiert sein sol- 
len. Gegeben sei weiterhin die Abbildung highlight, welche einen Term seiner Visualisierung 
zuordnet. Dann soil fur zwei beliebige Musikobjekte a und b gelten: 
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highlight (a ++ b) = highlight a ++ highlight b 
highlight (a =:= b) = highlight a =:= highlight b 

Wenn man alle Symbole hervorhebt, die mittelbar an der Erzeugung eines NoteOn- oder NoteOf f- 
MIDI-Kommandos beteiligt waren, dann erhalt man eine Funktion highlight mit diesen Eigen- 
schaftcn. Allcrdings fiihrt sie dazu, dass die Notenaufrufe kumulativ hervorgehoben werden. In 

note qn c ++ note qn d ++ note qn e ++ note qn f 

werden bei Wiedergabe von note qn e auch note qn c mid note qn d hervorgehoben, denn diese 
erzeugen Listen und dass diese Listen endlich sind, ist ein Grund dafiir, dass aktuell note qn e 
wiedergegeben werden kann. Die Aufrufe note qn c und note qn d sind also notwendigerweise 
daran beteiligt, dass note qn e reduziert werden kann. 

Zeitsteuerung Eine weitere Schwierigkeit besteht im zeitlich prazisen Versand der MIDI-Kom- 
mandos. Bislang wartet der Interpreter bis zu dem Zeitpunkt, an dem eine MIDI-Nachricht ver- 
schickt werden soli, und beginnt dann erst mit der Berechnung des entsprechenden Listenelements. 
Wir vertrauen also darauf, dass die Berechnung schnell genug beendet wird und sich der Versand 
nicht allzu stark verzogert. Bei komplizicrtcrcn Bcrcchnungcn trifft diese Annahme natiirlich nicht 
zu. Eine hohere Prazision konnten wir erreichen, indem wir die MIDI-Nachrichtcn mit einem 
Zeitstempel versehen und einige Zeit im Voraus verschicken. Das wirft neue Probleme der Syn- 
chronisation von Musik und grahscher Darstellung des Interpreterzustandes auf und es wurde 
auch heifien, dass die Musik erst verzogert angehalten werden kann und man nur verzogert in 
einen anderen Ausfuhrungsmodus wechseln kann. 

5 Danksagungen 

Dieses Projekt basiert auf einer Idee von Johannes Waldmann, die ich gemeinsam mit ihm entwi- 
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Informationen iiber dieses Projekt zu Programmentwicklung, Dcmonstrationsvideos und Arti- 
keln konnen Sie unter 

http : //www . haskell . org/haskellwiki/Live-Sequencer 
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